Asynchronous busses are used to provide very high speed transfers of information between I/O devices and host computers. Unlike synchronous busses, which rely on a central clock for controlling data exchanges and are thus bandwidth limited by the clock speed, asynchronous busses have no central clock associated with them that I/O devices and host computer I/O modules might use for generating bus transfer signals. Asynchronous busses rely instead on "handshake" signalling. Asynchronous bus speeds are limited only by the speed at which these handshake signals are exchanged.
For an asynchronous bus interface such as the IEEE 896.1-1991 Futurebus+ interface, transfers are divided into phases separated by handshakes. The first phase of a cycle is typically an address/command phase. The bus "master" requesting information asserts address and command information on the bus, and drives an address strobe signal indicating valid information. The "slave" device recognizes the assertion of the address strobe, examines the address/command information on the bus, and asserts an address "handshake" signal to the master indicating that it has received the information, thus setting up a bus "connection". The master then enters a data phase. The master asserts a data strobe signal to the slave, indicating that either data is available on the bus for the slave to latch, or that the master is ready to receive data from the slave. The slave either reads or asserts data on the bus, and releases a corresponding data handshake signal to indicate it has finished. Multiple data transfers may occur during the data phase of a single bus connection.
In order to maintain maximum bus throughput, the slave must generate data handshake signals as quickly as possible. The slave, however, is also responsible for generating local strobes to strobe data to and from the module after taking appropriate propagation delays into account. During a read, the slave must wait to generate the local read strobe for latching the data until the data has propagated from the slave to the bus. The data handshake must be correspondingly delayed. Likewise, during a write, the slave must wait to generate a local write strobe until the data has propagated from the master to the slave. The data handshake for the write must also be correspondingly delayed. These propagation delays vary depending on output driver enable times, input driver hold times, and on the number of bus transceivers the data must propagate through for a given transfer. In particular, where a master of one bus width is communicating with a slave of a different bus width, bus switching delays are incurred on some of the data transfers during a single data phase, resulting in variable beat delays for one data phase.
In many typical asynchronous bus interface designs, logic is provided to delay data strobe generation and handshakes on all transfers for as long as the longest possible transfer time that might be required for a given data transfer. This method is relatively simple to implement, and guarantees that data will always be valid when latched. However, this method is disadvantageous because valuable time is wasted by handshaking all other data transfers at speeds slower than the actual hardware capability allows, thus decreasing I/O bandwidth and throughput.
Other asynchronous bus interface designs may employ synchronous state machines to vary the timing of the local strobes and handshake signals for a given transfer. These synchronous machines must rely on a local module clock, since there is no central bus clock. Hence, a master handshake signals must be re-synchronized to the local clock, also wasting valuable time. Also, as asynchronous bus transfer speeds increase, the clock speed needed to supply a reasonable transfer time with minimal synchronization delay becomes impractical in terms of noise and metastability considerations.
Therefore, for asynchronous bus interfaces in which propagation delays may vary depending on cycle type, it is desireable to provide asynchronous logic for generating asynchronous bus strobes and handshake signals on an individual basis depending upon the propagation delay incurred for a given data transfer during a bus transaction, in order to minimize transaction times and increase bus bandwidth and throughput.